A bus architecture of a computer system conveys much of the information and signals involved in the computer system's operation. In a typical computer system, one or more busses are used to connect a central processing unit (CPU) to a memory and to input/output elements so that data and control signals can be readily transmitted between them. When the computer system executes its programming, it is imperative that data and information flow as fast as possible in order to make the computer system as responsive as possible to the user. With many peripheral devices, such as graphics adapters, full motion video adapters, small computer systems interface (SCSI) host bus adapters, and the like, it is imperative that large block data transfers be accomplished expeditiously. These applications are just some examples of subsystems which benefit substantially from a very fast bus transfer rate.
Much of a computer system's functionality and usefulness to a user is derived from the functionality of the peripheral devices. For example, the speed and responsiveness of the graphics adapter is a major factor in a computer system's usefulness as an entertainment device. Or, for example, the speed with which video files can be retrieved from a hard drive and played by the graphics adapter determines the computer system's usefulness as a training aid. Hence, the rate at which data can be transferred among the various peripheral devices often determines whether the computer system is suited for a particular purpose. The electronics industry has, over time, developed several types of bus architectures. Recently, the PCI (peripheral component interconnect) bus architecture has become one of the most widely used, widely supported bus architectures in the industry. The PCI bus was developed to provide a high speed, low latency bus architecture from which a large variety of systems could be developed.
Prior Art FIG. 1 shows a typical PCI bus architecture 100. PCI bus architecture 100 is comprised of a CPU 102 and a main memory 104, coupled to a host PCI bridge containing arbiter 106 (hereafter arbiter 106) through a CPU local bus 108 and memory bus 110, respectively. A PCI bus 112 is coupled to each of PCI agents 114, 116, 118, 120, 122, 124 respectively, and is coupled to arbiter 106.
Referring still to Prior Art FIG. 1, each of PCI agents 114, 116, 118, 120, 122, 124 (hereafter, PCI agents 114-124) residing on PCI bus 112 use PCI bus 112 to transmit and receive data. PCI bus 112 is comprised of functional signal lines, for example, interface control lines, address/data lines, error signal lines, and the like. Each of PCI agents 114-124 are coupled to the functional signal lines comprising PCI bus 112. When one of PCI agents 114-124 requires the use of PCI bus 112 to transmit data, it requests PCI bus ownership from arbiter 106. The PCI agent requesting ownership is referred to as an "initiator", or bus master. Upon being granted ownership of PCI bus 112 from arbiter 106, the initiator (e.g., PCI agent 116) carries out its respective data transfer.
Each of PCI agents 114-124 may independently request PCI bus ownership. Thus, at any given time, several of PCI agents 114-124 may be requesting PCI bus ownership simultaneously. Where there are simultaneous requests for PCI bus ownership, arbiter 106 arbitrates between requesting PCI agents to determine which requesting PCI agent is granted PCI bus ownership. When one of PCI agents 114-124 is granted PCI bus ownership, it initiates its transaction (e.g., data transfer) with a "target" or slave device (e.g., main memory 104). When the data transaction is complete, the PCI agent relinquishes ownership of the PCI bus 112, allowing arbiter 106 to reassign PCI bus 112 to another requesting PCI agent.
Thus, only one data transaction can take place on a PCI bus at any given time. In order to maximize the efficiency and data transfer bandwidth of PCI bus 112, PCI agents 114-124 follow a definitive set of protocols and rules. These protocols are designed to standardize the method of accessing, utilizing, and relinquishing PCI bus 112, so as to maximize its data transfer bandwidth. The PCI bus protocols and specifications are set forth in an industry standard PCI specification (e.g., PCI Specification--Revision 2.1). Where each of PCI agents 114-124 are high performance, well designed devices, data transfer rates of up to 528 Mbytes per second can be achieved (e.g., PCI bus 112 operating at 66 MHz).
When the number of PCI agents on a PCI bus is large, total data transfer bandwidth can quickly be consumed. The computer system incorporating such a PCI bus can be significantly slowed as the devices on the PCI bus contend for bandwidth. In addition, with a large number of PCI agents coupled, the ability to add still more PCI agents can be limited by the electrical properties of bus, or the lack of available expansion connectors. In such a case, system designers often incorporate one or more "bridges".
Generally, a bridge is a device designed to link two separate bus systems. Bridges can be used to connect similar (e.g., PCI to PCI bridge) or dissimilar (e.g., PCI to ISA bridge) bus systems. A bridge functions by transferring data from devices on one of the coupled busses to devices on the other.
In the case of two separate PCI busses, a PCI to PCI bridge (e.g., PCI bridge 124) is used to communicatively link PCI devices on one PCI bus to the PCI devices the other PCI bus. A PCI bridge electrically separates devices on one PCI bus from devices on the other while still allowing them communicate with each other. This solves problems with respect to, for example, too many electrical loads on one PCI bus, incompatible bus latency requirements between devices, or the limited number of PCI expansion connectors supported. The PCI bridge includes the necessary logic required to transfer data signals from one PCI bus to the other. Hence, although the PCI bridge has the above advantages, the necessary logic included in the PCI bridge adds latency and delay to data transactions which cross the PCI bridge.
In the case of a PCI to ISA or some other type of bus, the bridge (e.g., ISA bridge 118), in addition to data transfer logic, includes logic for translating data transactions from one bus protocol to another, in this case PCI to ISA and ISA to PCI. The ISA bridge solves the same sorts of problems the PCI bridge solves, however, since the ISA bus runs much slower than the PCI bus, the ISA bridge, as with other types of bridges, typically functions much slower and has much greater effective latency than the devices on the PCI bus (e.g., PCI bus 112).
To deal with this latency, prior art bridges (e.g., PCI bridge 124 and ISA bridge 118) support delayed transaction protocols. Delayed transaction protocols (or simply, delayed transactions) are defined by the PCI specification. Delayed transactions allow a more efficient utilization of PCI bus bandwidth by providing for a more efficient flow of data between an initiator device one side of the PCI bridge and a slower target device on the other. Delayed transactions allow ISA bridge 118, for example, to issue a retry to the initiator (e.g., CPU 102) if the data transaction will take an inordinate amount of time to complete. This allows the ISA bridge 118 to work on completing the data transaction with the target device while freeing PCI bus 112 for use by another initiator. In the meantime, ISA bridge 118 works on the data transaction, for example, fetching the requested data from a CD-ROM coupled to the ISA bus and loading its internal read FIFO (first-in-first-out) buffer. When the retried initiator subsequently reattempts its access, ISA bridge 118 supplies the requested data.
There is a problem, however, in that ISA bridge 118 (as with other typical prior art bridges) retries all subsequent initiators seeking access to devices on the ISA bus while fetching the requested data from the first initiator. Consequently, there exists the possibility for one or more initiators to be "starved" from obtaining access to devices residing on the ISA bus. For example, if initiator 114 (motion video device) writes a block of data to a shared memory device on the ISA bus on the other side of ISA bridge 118, ISA bridge 118 might then consider itself busy (e.g., its internal write FIFO fills up) and retry all further PCI cycles until its internal write FIFO empties.
If a different initiator, for example, initiator 120 (audio device) is granted PCI bus 112 right after initiator 114 and attempts to access any device residing on the ISA bus, it is retried because the internal write FIFO of ISA bridge 118 is still full. Initiator 114 reattempts its access at just the right time to find ISA bridge 118 available (e.g., its write FIFO has been emptied by writes on the ISA bus to the memory device). So initiator 114 again writes a block of data to the shared memory device via ISA bridge 118, again filling the internal write FIFO. Initiator 120 again is granted PCI bus 112 but is retried because initiator 114 has filled the write FIFO of ISA bridge 118. In this manner, it is quite possible initiator 120 will be prevented from obtaining access to ISA bridge 118. This starvation can continue long enough for initiator 120 to lose data (e.g., internal FIFO to be over run). This is especially damaging for devices with internal FIFOs which must be filled or emptied on a regular basis. Such devices include, for example, USB (Universal Serial Bus) devices, IEEE 1394 Fire Wire devices, interfaces to LANs (local area network), and the like. The same scenario is possible for PCI read cycles, as well PCI write cycles.
The conventional prior art approach to solving this problem involves increasing the size of the read and write FIFOs in the bridge devices (e.g., ISA bridge 118) and to add support for multiple delayed transactions. Increasing the FIFO sizes involves using larger registers, larger buffers, etc, and more sophisticated logic to support multiple delayed transactions. Adding support for multiple delayed transactions involves adding support logic for saving initiator address and command/byte enable information. This allows a bridge to determine when an initiator reattempts an access from which the initiator was previously retried. As described above, upon an initial access attempt, a bridge will issue a retry to free the PCI bus while it works on completing the data transaction. As soon as that initiator's requested data is available and the initiator retries its previous access, the bridge, having saved that initiator's address and command/byte enable information, recognizes the access and presents the requested data to the initiator. In this manner, the bridge supports multiple devices by saving the initiator address and command/byte enable information for each initiator being "queued". This allows the bridge to subsequently execute each of the delayed transactions, using the saved address and command/byte enable information for each queued initiator, in sequence, as each previous transaction finishes.
The problem with this approach is that it is gate intensive and complicated. Increasing the size of the read and write FIFOs and storing the address and command/byte enable information for multiple initiators consumes a large amount of circuitry. The implementing logic (e.g., gates, connect lines, registers, etc.) consumes a relatively large amount of silicon area in comparison to the other functions included within a bridge. Consequently, the prior art approach is expensive.
Thus, what is required is a system which supports delayed transactions without incurring the increased complexity and expense associated with the prior art. The required system should allow fair access between devices on either side of a bridge. The required system should not allow a device to be starved of access to other devices on the other side of the bridge. In addition, the required system should confer its benefits without requiring a large amount of implementing logic. The present invention provides a novel solution to the above requirements.